Building new products that people love is hard, mostly because it is a complex process that takes a long time. It asks us to learn from our mistakes in a context where going back to fix errors is never well-received.
The process of making something great requires both creativity and discipline. Many products fail because these two parts don’t support each other; instead, they limit one another.
Limiting creativity with a strict process driven by managers will result in a boring and useless product. Relying on the maker’s creativity alone will get you to 80% quickly, but you will never be able to put the finishing touches on the important details.
Over many years, I have seen products fail because of ego, creative castration and a lack of discipline. The need for quality products today is too great to waste time and talent.
By making products at Translated and Memopal and by observing so many great startups, I have devised a method that aims to deliver the required balance of creativity and discipline, a fast and pre-approved way to go back and fix errors that also incorporates two common elements of successful products: vision and psychology.
The minimum team is composed of:
- The Product Manager, who has the task of leading.
- The User(s), who have the task of expressing the pain points and their importance. The user is an early adopter who has expressed an interest in buying/using your product.
- The Developer(s), who have the task of finding solutions to the user’s pain points and estimating their costs.
If you are a single founder, I suggest that you play the role of the product manager and, if possible, get someone onboard as a developer. Single founders can play the dual role of the PM and developer, but this is not ideal because it results in a natural urge to stay in the comfort zone, something that this method is designed to avoid.
Most people make products without the user in the initial loop. I think this is a bad idea. To succeed without the user, you will need a lot of luck, and users are much more abundant than luck.
Identify pains
Multiple 1-hour meetings. The user will express their perceived pain. The product manager will ask questions to clarify and delve deeper until the real root of the pain point is exposed. The developers will be silent observers. This is where the quality of the PM becomes clear: how deep can they delve into the roots of the pain point without being considered a jerk? The user will generally attempt to please the PM, saying that he or she would love that problem to be solved. However, the PM should not listen to what users say: the PM should look at what they do. To do so, I often suggest simulating the idea that there is already a product that solves the problem and that is called X and costs Y. I would then say “Do you want me to get one for you now?”. If the user says “yes”, you have identified a perceived pain worth acting on; if the user says “no” or starts adding extra requirements and complications, you should start the process again. The PM will convert each pain point into a task.
Add vision
Multiple 1-hour meetings to discuss how the product will ideally look in the future. Participants should not feel that this is what they are being asked to build now, but what they think will be possible one day. The product manager will ask the developers how they think it could be possible to surpass the expectations of the user, taking into account their perceived pains. They will talk about what the technology could potentially do. The PM should ask the user the same and provide their own view at the end. Normally, the PM owns the vision, but by going last they ensure that they can leverage the creativity of the participants. The discussion should go on until the PM agrees that the future product will be technically feasible and loved by the user. The product manager will convert the ideas into tasks.
Add pathos
Most successful products give users something more than just the solution to a perceived problem.
Addressing vanity, laziness and the desire for something that we cannot have are some of the common elements of great products. These meetings work best if they only involve the PM, the user, and an intimate conversation. The PM should put the user in the position of discussing their work or life and forget about building the product for a moment. The PM should ask the user what makes them look better than their peers, what makes them bored and what they want that they cannot have. This will be translated into tasks.
Set priorities and releases All the tasks derived from the pain points, vision and psychology will be inserted into a table like the one below:
| Task | $ Cost | $ Impact | Priority |
|---|---|---|---|
| Make users right-click on the photo to share it | 2,000 | 10,000 | 5.0 |
| Release 1 | |||
| Zoom photos | 1,500 | 5,000 | 3.3 |
| Support Android | 10,000 | 10,000 | 1.0 |
| Release 2 | |||
| Automatic organization of photos | 50,000 | 25,000 | 0.5 |
| Automatic starring of best photos | 20,000 | 5,000 | 0.2 |
| Release 3 | |||
Cost is an estimation of the total cost of the task; this should only be filled in by the engineers. Impact is a score or economic value associated with the task. This should only be filled in by the users, possibly without seeing the cost. The important aspect is not the number itself but the ratio between the tasks. If one task is twice as valuable as another, its impact should be twice as big. The PM should challenge the engineers and the user to make sure the estimations are correct. The PM will calculate the priority as impact/cost and rank the tasks in descending priority order. The PM, with the help of the user and the engineers, will draw horizontal lines to plan releases.
Grouping tasks into releases by priority guarantees that the maximum value for money is delivered in the first release. This is critical for product/market fit. If the desired value proposition is not clear in the first release, the PM should challenge the previous numbers and/or reconsider the value proposition itself. You may find that the addressed pain point is actually not worth working on.
Review
Make the product Release 1 and ask the user to use it. Ask for pre-orders at a fair discount, since you are dealing with the alpha product. If the user pre-orders, go to Release 2 and iterate again.
If the user does not pre-order because they do not feel that the product is addressing the pain point, go back and identify the pain points again. If, after a few cycles, the user still does not pre-order, the weakest factor among the user, the developer and the PM should be replaced and the cycle re-started.
Beyond creativity and discipline, if you want to build good products you have to be prepared to either make big sacrifices or hope for a lot of luck. If you want to make a great product, you will need both.